1. Field of the Invention
This invention relates generally to wireless telecommunication. More particularly, it relates to wireless carrier location based services (LBS) and J2ME wireless client LBS related software and apparatus.
2. Background of the Related Art
Existing voice navigation systems typically use standard reusable voice prompts preloaded on client devices. These standard voice prompts are usually carefully crafted to be reusable in all situations. All situations match to a pre-loaded or concatenated voice prompt. However, the present inventor has appreciated that such existing navigation systems severely limit product usability and quality due to a compromise in prompt length, scope and quality in order to achieve the timing requirements.
Voice navigation systems written in Java Platform Micro Edition (J2ME) often produce late and missed voice prompts. This sometimes results in the absence of a street name in a voice prompt, e.g., just speaking “Turn Right in 500 feet”. The indicated pre-storage voice fragment files are concatenated at the time they are needed. Even the number is pre-stored and concatenated. This results in a situation where the voice prompt is not dynamic and does not have the street names and point-of-interest (POI) name.
Voice prompts in a J2ME navigation system are typically dynamically created (based on the client navigation, the location of the device during navigation) on a voice server and retrieved according to the product requirements. An exemplary product is the TCS Navigator product commercially available from TeleCommunication Systems, Inc. headquartered in Annapolis, Md. This first part, the prompt creation, is performed some time before the actual situation occurs in anticipation of the impending situation requiring a voice prompt. The voice prompt is cached on the client device (phone) for use in the very near future (usually a matter of seconds). This caching process is related to the present invention in that the invention solves a problem occurring upon use of a cached voice prompt.
FIG. 3 illustrates a conventional system for playing navigation voice prompts. In particular, the conventional system for playing navigation voice prompts includes hardware resources 140, asynchronous hardware interface, a media player 10, and a local storage 120. During startup, media player 10 reserves a portion of local storage as a buffer 11. A client navigation program 160 manages the media player 10.
In particular, the problem solved by the present invention comes in the stage when the navigation program 160 must play the voice prompt in a timely manner. Dynamic, location-based voice prompt files are passed from local storage 120 (via a pointer) to the asynchronous hardware interface 130 which must then acquire scarce or exclusive hardware resources 140 to allow the media player 10 to play the voice prompt file. The media player 10 needs to perform a number of time-consuming tasks before it is ready to be started, after receiving the voice prompt file. Additionally, these acquisition tasks must occur sequentially and the various states of the media player 10 must be managed by the client navigation program 160. After playing the voice prompt, the system's media player 10 must then release fully and completely these “scarce or exclusive hardware resources”, hardware resources 140, related to the specific voice prompt. This is because the exclusive hardware resources 140 can only be acquired after the handle to a specific voice prompt has been successfully passed into the media player's 10 interface. As a result, a client navigation program 160 may not acquire and hold these exclusive hardware resources 140 and simply replace the voice prompt contained within the hardware resources 140.
As a result, timing is very important in navigation systems, not only for product quality but also for the safety of those using a navigation product. Therefore a client navigation program 160 must play timely and accurate voice prompts.